United States Patent ri9] 

Holden et al. 



US005828832A 
[ii] Patent Number: 
[451 Date of Patent: 



5,828,832 
Oct, 27, 1998 



[54] MIXED ENCLAVE OPERATION IN A 
COMPUTER NETWORK WITH MULTI- 
LEVEL NETWORK SECURITY 

[75] Inventors: James M. Holden, Valley Center; 

Stephen E. Levin, Poway; Edwin H. 
Wrench, Jr., San Diego, all of Calif.; 
David W. Snow, deceased, late of 
Co vent Station, N.J, 

[73] Assignee: ITT Industries, Inc., White Plains, 
N.Y. 

[21] Appl. No.: 688,524 
[22] Filed: Jul. 30, 1996 



[51] Int. CI. 6 G06F 11/00 

[52] U.S. CI 395/187.01; 395/186; 395/187.01; 

395/188.01; 395/200.59 

[58] Field of Search 395/186, 187.01, 

395/188,01, 218, 244, 200.5 



[56] References Cited 

U.S. PATENT DOCUMENTS 

4,896,319 1/1990 Lidinsky et al 370/60 

5,204,961 4/1993 Barlow 395/725 

5,548,721 8/1996 Denslow 395/187.01 

5,692,124 11/1997 Holden et al 395/187.01 

Primary Examiner — Robert W. Beausoliel, Jr. 
Attorney, Agent, or Firm — Plevy & Associates 

[57] ABSTRACT 

A method is disclosed for mixed enclave operation of a 
computer network with users employing a multi-level net- 
work security interface and users without any network 
security interface. Either the network security user selects or 
the network security interface automatically selects whether 
communications are permissible with other unsecured users. 
Where a mixed enclave operation is selected, the network 
security user identifies when communications are being 
undertaken with another secured user or a non-secured user. 
Communications with a non -secured user at a lower security 
level entail securing the data residing with the secured user 
from transmission back to the non-secured user. 

20 Claims, 5 Drawing Sheets 
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MIXED ENCLAVE OPERATION IN A Boeing MLS LAN, for instance, the backbone cabling is 

COMPUTER NETWORK WITH MULT1- replaced by optical fiber and all access to the backbone is 

LEVEL NETWORK SECURITY mediated by security devices. In the Verdix VSLAN, similar 

security devices are used to interface to the network, and the 

RELATED APPLICATIONS 5 network uses encryption instead of fiber optics to protect the 

<-»-« • , ~ . . * , security of information transmitted between devices. 

The Assignee herein, IT1 Corporation, is the record , /cl A ^ T . , . . . u ^ 1 

owner of copending U.S. application Ser. No. 08/270,398 to VSL ^ * ^t^Tll™ ' ™ DC,W0 * (LAN) 

Boyle et al., emitted APPARATUS AND METHOD FOR aS 1S thc B ° C1Dg 

PROVIDING MULTI -LEVEL SECURITY FOR COMMU- rrustcd hosts are hosl computers that provide security for 

NICATION AMONG COMPUTERS AND TERMINALS 10 a network by reviewing and controlling the transmission of 

ON A NETWORK, filed Jul. 5, 1994. a ^ ^ata on networ k- For example, the U.S. National 

Security Agency (NSA) has initiated a program called 

FIELD OF THE INVENTION Secure Data Network System (SDNS) which seeks to imple- 

. , ment a secure protocol for trusted hosts. In order to imple- 

Die present invention relates in general to computer 15 mem this a pp roach , the installed base of existing host 

networks and in particular to communications in a computer computers must be upgraded l0 ^ the xcuze {ocol 

network environment with multi-level secure network users Such systems operale at lhe Nelwork Qf Transport Layers 

and non-secure network users. (LayefS 3 Qr 4) of ^ Qpen Syslems Interconnection (0S I) 

BACKGROUND OF THE INVENTION M model * 

Encryption devices are used in a network environment to 

Multi-level secure (MLS) networks provide a means of protect the confidentiality of information. They may also be 

transmitting data of different classification levels (i.e. usec j f or separation of data types or classification levels. 

Unclassified, Confidential, Secret and Top Secret) over the p ac k e t encryptors or end-to-end encryption (EEE) devices, 

same physical network. To be secure, the network must f or instance, utilize different keys and labels in protocol 

provide the following security functions: data integrity W headers to assure the protection of data. However, these 

protection, separation of data types, access control, authen- protocols lack user accountability since they do not identify 

tication and user identification and accountability. wn ich user of the hosi is using the network, nor are they 

Data integrity protection ensures that data sent to a capable of preventing certain users from accessing the 

terminal is not modified enroute. Header information and network. EEE devices typically operate at the Network 

security level are also protected against uninvited modifi- 30 Layer (Layer 3) of the OSI model. There is a government 

cation. Data integrity protection can be performed by check effort to develop cryptographic protocols which operate at 

sum routines or through transformation of data, which other protocol layers. 

includes private key encryption and public key encryption. An area of growing concern in network security is the use 

Separation of data types controls the ability of a user to 35 of computer devices in non-secure networks. Such computer 

send or receive certain types of data. Data types can include devices often include valuable information, which may be 

voice, video, E-Mail, etc. For instance, a host might not be lost or stolen due to these computers being accessed through 

able to handle video data, and, therefore, the separation the non-secured network. In light of this problem, a number 

function would prevent the host from receiving video data. of related products have been developed. The products 

Access control restricts communication to and from a 4Q developed include Raptor Eagle, Raptor Remote, Entrust, 

host. In rule based access control, access is determined by Secret Agent and Veil. Although, these products serve the 

the system assigned security attributes. For instance, only a same purpose, a number of different approaches have been 

user having Secret or Top Secret security clearance might be utilized. For example, Raptor Eagle, Raptor Remote, and 

allowed access to classified information. In identity based Veil implement these products as software instantiations, 

access control, access is determined by user-defined 45 While Entrust and Secret Agent utilize hardware crypto- 

attributes. For instance, access may be denied if the user is graphic components. Additionally, Raptor products are also 

not identified as an authorized participant on a particular application independent. 

project. For control of network assets, a user may be denied A problem with the above described products is that none 

access to certain elements of the network. For instance, a are based upon the use of highly trusted software. Veil is an 

user might be denied access to a modem, or to a data link, 50 off-line encryption utility, which cannot prevent the inad- 

or to communication on a path from one address to another vertent release of un-encrypted information. While Raptor 

address. Eagle and Raptor Remote are based on software instantia- 

Identification of a user can be accomplished by a unique tions and thus cannot be verified at the same level of 

name, password, retina scan, smart card or even a key for the assurance. Secret Agent and Entrust while hardware based 

host. Accountability ensures that a specific user is account- 55 are dependant upon the development of integration software 

able for particular actions. Once a user establishes a network for specific applications. 

connection, it may be desirable that the user's activities be Many network security devices, also referred to as Inline 
audited such that a "trail" is created. If the user's actions do Network Encryptors (INE), provide privacy for all traflic 
not couform to a set of norms, the connection may be leaving a network by encrypting the traffic. The limitation of 
terminated. 60 sucri devices lies where a network needs to accommodate 
Currently, there are three general approaches to providing communications between secure network users and non- 
security for a network: trusted networks, tnisted hosts with secure network users. An Internet including both secure and 
trusted protocols, and encryption devices. The trusted net- non-secure users is referred to as a "Mixed Enclave". Once 
work provides security by placing security measures within a secure user operates under a security device, such as an 
the configuration of the nelwork. In general, the trusted 65 Inline Network Encryption (INE), that user can only corn- 
network requires that existing protocols and, in some cases, municate with other users with similar security devices or 
physical elements be replaced with secure systems. In the INEs with the same keys. 
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Accordingly, an object of the present invention is to nications between a user such as a computer host and a 
provide for a multi-level network security apparatus a network at a "session layer" of interconnection which occurs 
method of communications in a mixed enclave network when a user on the network is identified and a communica- 
system between both users communicating with and users "on session is to commence. For example, the industry- 
communicating without the multi-level network security 5 standard Open Systems Interconnection (OSI) model, 
apparatus. defines seven layers of a network connection: (1) physical; 

(2) data link; (3) network; (4) transport; (5) session; (6) 

SUMMARY OF THE INVENTION presentation; and (7) application. In the present invention, 

^ . . , , „ the network security measures are implemented at the Ses- 

The present invention provides a method for mixed sion Layer 5. The placement of security at the Session Layer 

enclave communications over a network including both ™ alk)WS exigti network assets and exisU netwofk _ 

secured and unsecured users. The method entails permitting cds at (he Transporl Uyer 4 and lower t0 continue t0 be 

communications over the network between the secured users ^ thereby avoiding the need t0 replace an installed 

and unsecured users, the secured user discovering dynami- netWQrk base for |he imp , ern entation of the multi-level 

cally whether a user initiating communications is another security system The connected host or ^ equipm ent and 

secured user or an unsecured user, and, controlling passage ^ lhe netWQrk backbone are therefore not required t0 be sccn „ 

of information between a secured user and an unsecured user (trusted ). Conventionally, OSI network applications employ 

tor securing given information residing with the secured ccnT x 2l5 which Ls a non _ seaire session layer protocoh 

user against unintentional transference to an unsecured user. None of the prior multi-level security systems employ the 

Preferably, the secured user operates under an Inline Net- security measures described herein in the Session Layer, 

work Encryptor (INE). ^ SNIU according t0 the presen t invention can be 

Discovering whether communications are with another configured in a number of different embodiments depending 

secured user or an unsecured user, utilizes Internet protocol on lhe part icular physical locations and forms of implemen- 

(IP) addresses for identifying the secured and unsecured lalion embodiments include a stand alone hardware 

users, using association establishment messages for the SNIU and a software SNIU 

secured users authenticating each other using association 25 The hardwafe embodiment of the SNIU is implemented 

establishment messages for the secured users exchanging solel ^ a stand alone hardware device< S uch a configura- 

security parameters. For communications between one of ^ is desirablej since the stand alone SNIU is highly 

the secured users and one of the unsecured users, the secured tnJSted The stand alone smv [s configured t0 be inserted 

user employs a waiting queue to influence passage of 3o between existing hog|s and a nelW0fk The SNRJ ^ trans . 

information. When one of the secured users receives initial paren( tQ the hostj and any kgacy system Qf applicalion 

information from one of the unsecured users that is not software inning on the host. The stand alone SNIU pro- 

already established, the secured user creates an entry in an yides protection for any host conn ected to an IP based 

association table indicative of at least the unsecured user's network There is nQ requir ement that the attached host 

IP address and association type. When the secured user 35 computcrs a trusted operating system. The stand alone 

further compares its security level to that of the unsecured SNIU provides a tnisled boiin dary between the protected 

user for determining if information to the unsecured user can hosts and the unproteclcd netW ork. Protected means that the 

be allowed to proceed. connection is with another known SNIU (a unique digital 

BRIEF DESCRIPTION OF THE DRAWINGS signature identifies the SNIU), the messages are confidential 

4 o (encrypted) and unaltered (cryptographic residues validate 

The invention will be better understood with reference to the packet), 

the following illustrative and non-limiting drawings, in The software embodiment of the SNIU is implemented 

which: solely as a software function resident in and executed from 

FIG. 1 is a schematic diagram of an MLS network system the host machine. Such a configuration is desirable, since the 

in accordance with the present invention; 45 software SNIU is designed to be installed in existing por- 

FIG. 2 is a block diagram of the software SNIU installed ,able computers, which avoids the additional cost of addi- 

in a computer host in accordance with the present invention; tional hardware required by a stand alone hardware SNIU. 

FIG. 3 is a data flow diagram for the software SNIU in softwar L e SN ™ provides the same network security 

accordance with the present invention; features a ? th * stand alone S * IU ^ ih ^ hos \ com ^^ 

i-t^ a ■ «i 1 ■ 1 £ A f L , AJJ 50 connected to home enterprise s network. The software SNIU 
FIG. 4 is a tabic showrng the format for the Address ako exlends ^ sa[ne £ , f rf aeross ^ MKmt 

Resohmon Protocol and Reverse Address Resohmon Pro- {q[ olhef ^ network) when the ^ ^ on the 

tocol messages in accordance with the present invention; j j • , 1 • *• ,u ^ 

& K ' road and ls remotely communicating with the enterprise 

FIG. 5 is a table showing the data structure for a token ol ne twork or other remotely located computer devices includ- 

the Association Table in accordance with the present inven- $s ing a similar softwarc sim j. 

tl0n; and The software SNIU provides all of the functionality and 

FIG. 6 is a table showing the data structure of a token for security of the stand alone SNIU as well as complete 

the Sym_Key Table in accordance with the present inven- operability with these devices. The software comprising the 

tl0n software SNIU is based on the same software utilized in the 

FIG. 7 is a flow chart of the steps for limited write downs go stand alone hardware SNIU. The user of the software SNIU 

of data from lower classificaiion security levels to higher assumes an acceptable risk in exchange for not requiring 

classification security levels. additional hardware required by a stand alone SNIU, which 

cannot be circumvented or corrupted via attacks from origi- 
nating from external hardware. By providing reasonable 

65 software protection (not allowing unauthorized personal 

The present invention is directed to a secure network physical access) and software protection (anti-virus 

interface unit (SNIU), which is utilized to control commu- protection), a software SNIU can be utilized providing the 
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user with an acceptable level of risk. If the user is confident 
that the software comprising the software SNIU is not 
circumvented or modified, then he can enjoy the same 
degree of confidence as the user of a stand alone device. 

Referring to FIG. 1, there is shown an example of a s 
Multi-Level Security (MLS) System in accordance with the 
present invention This system 10 incorporates the various 
embodiments of the SNIUs in order to provide MLS for 
computer networks such as the Internet. For example, the 
guard devices 14,16 which are hardware embodiments of the io 
SNIU are coupled between computer networks 34,36,38 
providing inter-network security. Additional guard devices 
12,18 are coupled between users such as computer hosts 
2830,32 and the respective networks 30,32,34. The soft- 
ware embodiment of the SNIUs are implemented as a 15 
companion within computer hosts 24,26, to provide network 
security without requiring additional hardware. The auditors 
20,22 are also hardware SNIUs which are configured to 
communicate directly with the other SNIUs to log audit 
events and potentially signal alarms. The above described 20 
system 10 enables secured and non-secured users such as a 
web site 40 to communicate with each other without the 
danger of compromising security. 

During operation, the SNIUs included in the above 
described system 10 communicate with each other thereby 25 
creating a global security perimeter for end-to-end commu- 
nications and wherein the network may be individually 
secure or non-secure without compromising security of 
communications within the global security perimeter. The 
SNIUs are capable of passing digital data, voice and video 30 
traffic so as to provide the full functionality required for a 
Trusted Session Protocol (TSP). The TSP uses the facilities 
of the lower level protocols to transmit data across the 
networks. To this end, and to provide flexibility, the spe- 
cialized network interface SNIU is designed to allow cou- 35 
pling of the TSP with existing (non-secure) equipment and 
underlying network. 
Security System Policies 

The SNIU devices in accordance with the present inven- 
tion may implement a number of security policies suitable to 40 
the circumstances of a given network environment. The 
major policy areas are: discretionary access control; man- 
datory access control; object reuse; labeling; identification 
and authentication; audit; denial of service detection; data 
type integrity; cascading control; and covert channel use 45 
detection. 

Discretionary access control is a means of restricting 
access to objects (data files) based on the identity (and need 
to know) of the user, process, and/or group to which the user 
belongs. It may be used to control access to user interface 50 
ports based on the identity of the user. For a single-user 
computer unit, this mechanism may be implemented in the 
SNIU, whereas for a multi-user host, the DAC control may 
be implemented at the host machine. Discretionary access 
control may also be implemented as discretionary dialog 55 
addressing, wherein the addressing of all communications 
originated by a user is defined, and for user discretionary 
access denial, wherein a user may refuse to accept a com- 
munication from another user. 

Mandatory access control is a means of restricting access 60 
to objects based on the sensitivity (as represented by a 
classification label) of the information contained in the 
objects, and the formal authorization (i.e., clearance) of the 
user to access information of such sensitivity. For example, 
it may be implemented as dialog lattice-based access 65 
control, wherein access requires a correct classification 
level, integrity level, and compartment authorization, dialog 
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data-type access control, wherein correct data type authori- 
zation is required for access, and cascade protection, 
wherein controls are provided to prevent unauthorized 
access by cascading user access levels in the network. 

Object reuse is the reassignment and reuse of a storage 
medium (e.g., page frame, disk sector, magnetic tape) that 
once contained one or more objects to be secured from 
unauthorized access. To be secured, reused, and assigned to 
a new subject, storage media must contain no residual data 
from the object previously contained in the media. Object 
reuse protection may be implemented by port reuse 
protection, session reuse protection, dialog reuse protection, 
and/or association reuse protection. 

Labeling requires that each object within the network be 
labeled as to its current level of operation, classification, or 
accreditation range. Labeling may be provided in the fol- 
lowing ways: user session security labeling, wherein each 
user session is labeled as to the classification of the infor- 
mation being passed over it; dialog labeling, wherein each 
dialog is labeled as to the classification and type of the 
information being passed over it; and host accreditation 
range, wherein each host with access to the secured network 
is given an accreditation range, and information passing to 
or from the host must be labeled within the accreditation 
range. 

Identification is a process that enables recognition of an 
entity by the system, generally by the use of unique user 
names. Authentication is a process of verifying the identity 
of a user, device, or other entity in the network. These 
processes may be implemented in the following ways: user 
identification; user authentication; dialog source 
authentication, wherein the source of all communication 
paths is authenticated at the receiving SNIU before com- 
munication is allowed; SNIU source authentication, wherein 
the source SNIU is authenticated before data is accepted for 
delivery; and administrator authentication, wherein an 
administrator is authenticated before being allowed access to 
the Security Manager functions. 

An audit trail provides a chronological record of system 
activities that is sufficient to enable the review of an 
operation, a procedure, or an event. An audit trail may be 
implemented via a user session audit, a dialog audit, an 
association audit, an administrator audit, and/or a variance 
detection, wherein audit trails are analyzed for variance from 
normal procedures. 

Denial of service is defined as any action or series of 
actions that prevent any part of a system from functioning in 
accordance with its intended purpose. This includes any 
action that causes unauthorized destruction, modification, or 
delay of service. The detection of a denial of service may be 
implemented for the following condition: user session auto- 
matic termination, such as when unauthorized access has 
been attempted; user machine denial of service detection, 
such as detection of a lack of activity on a user machine; 
dialog denial of service detection; association denial of 
service detection, such as detection of a lack of activity 
between SNIUs; and/or data corruption detection, such as 
when an incorrect acceptance level is exceeded. 

Covert channel use is a communications channel that 
allows two cooperating processes to transfer information in 
a manner that violates the system's security policies. Detec- 
tion of covert channel use may be implemented, for 
example, by delay of service detection, such as monitoring 
for unusual delays in message reception, or dialog sequence 
error detection, such as monitoring for message block 
sequence errors. 
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Details Of ihe Software SNIU 

Referring to FIG. 2, a block diagram of the software SNIU 
installed in a computer host is shown. The software SNIU 44 
is implemented as a software function within a host com- 
puter 42. The SNIU 42 interfaces with the communications 
stack of the host computer 58 in order to send and receive 
messages over the Ethernet or token ring cable 74. The 
communications stack 58 is a typical OS1 model including 
a physical 72, data link layer 70, network layer 68, transport 
layer 66, session layer 64, presentation layer 62 and appli- 
cation layer 60. The network layer 68 includes an ARP/ 
RARP module which is utilized to process Address Reso- 
lution Protocol (ARP) and Reverse Address Resolution 
Protocol (RARP). As can be seen from FIG. 2, the SNIU 44 
is installed between the network and data link layers of the 
communications stack 68,70, which enables it to be trans- 
parent to the other high order software. 

The main modules of the SNIU include a Host/Network 
Interface 46, Session Manager 48, Trusted Computing Base 
50, Audit Manager 52, Association Manager 54 and Fortezza 
API 56. The primary data structures included in the SNIU 
are the Association Table, Sym__Key Table, Certificate 
Table, Waiting Queue and Schedule Table. These data struc- 
tures are described later in the description of the protocol. 

The Host/Network Interface 46 provides the interfacing 
between the SNIU 44 and communications stack 58. The 
Fortezza API 56 is a driver for the card reader 76 included 
in the host computer 42. The card reader 76 is adapted to 
receive a Fortezza card which is a PCMCIA card configured 
to perform integrity and authenticating functions. The 
Fortezza card performs the integrity function by encrypting 
messages leaving the SNIU 44 and decrypting incoming 
messages. The authentication function is accomplished by 
the Fortezza card generating and reading digital signatures 
which are unique to each SNIU. The Fortezza card includes 
a private key to generate the digital signature and a public 
key to read the signatures. The other SNIU modules will be 
described in conjunction with data flow diagram of FIG. 3. 

Referring to FIG. 3, there is shown a data Mow diagram 
for the software SNIU. When the host computer communi- 
cates with another computer over a network, the communi- 
cations protocol stack within the computer processes the 
data to be transmitted. If a user on the computer is trans- 
mitting a file to another computer, the user may select the file 
to send by interacting with application layers software. The 
display which the user sees is controlled by presentation 
layer software. Session layer software checks the users 
permission codes to determine if the user has access to the 
file. Transport layer software prepares Internet Protocol 
Datagrams containing blocks of file data and determines that 
the transmitted file data is properly received and acknowl- 
edged or is re-transmitted. 

The Host/Network interface 46 is utilized to intercept the 
data packets transmitted between the network and data link 
layers 68,70. The interface 46 Ls utilized to format the data 
packets into an appropriate format depending on whether the 
data packet is incoming or out going. The interface 46 
accomplishes this by removing the hardware address header 
when it receives a data packet and re-applies the same 
header when the packet is released (even if the underlying IP 
address header was changed). Since the interface in the 
software SNIU 46 does not handle ARP and RARP message 
for the host computer, it can be smaller than the one utilized 
in the hardware SNIU. As previously described, the ARP/ 
RARP module included in the network layer 68 performs 
this function. 

When the untrusted Host/Network Interface 46 completes 
re-assembling an IP datagram from a host computer, the 
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datagram is passed to the Trusted Computing Base 50 (TCB) 
of the SNIU for processing. The TCB 50 is the collection of 
hardware and software which can be trusted to enforce the 
security policy. The TCB 50 includes a Scheduler module 

s 50A and a Message Parser 50B. The Scheduler 50A is 
utilized to control the flow of datagrams within the SNIU. 
The scheduler 50A provides timing for incoming datagrams 
and temporarily stores these datagrams in a buffer if earlier 
ones are being processed. 

io The Message Parser SOB is the first module in the TCB 
which processes an IP datagram received from the host 
computer. The Message Parser SOB checks the Association 
Table 76 and determines whether or not an association 
already exists for sending ihe datagram to its destination. If 

15 no association exists, the datagram is stored on the Waiting 
Queue and the Association Manager 54 is called to establish 
an association between this SNIU and the SNIU closest to 
the destination host. If an association does exist, the Session 
Manager 48 is called to encrypt the datagram, check security 

20 rules, and send the encrypted Protected User Datagram 
(PUD) to the peer SNIU. 

When the Association Manager 54 is called, it prepares 
two messages to initiate the association establishment pro- 
cess. The first message is an Association Request Message 

25 which contains the originating host computer level and this 
SNIU's certificate (containing it's public signature key). 
This message is passed to the Fortezza API 56 which 
controls the Fortezza card which signs the message with this 
SNIU's private signature key. The second message is an 

30 I CMP Echo Request message which will be returned to this 
SNIU if it is received by the destination host. Both messages 
are passes to the network-side Host/Network Interface Mod- 
ule 46 to be transmitted to the destination host. 

When a SNIU receives messages, the messages are first 

35 processed by the SNIU's receiving port's Host/Network 
Interface 46 which reassembles the messages and passes 
them to the trusted software. The Message Parser module 
50B passes the Association Request Message to the Asso- 
ciation Manager 54 module and deletes the ICMP Echo 

40 Request message. The Association Manager 54 passes the 
message to the Fortezza API 56 which verifies the digital 
signature. If not valid, the Audit Manager 52 is called to 
generate an Audit Event Message to log the error. If the 
signature is OK, the Association Manager 54 saves a copy 

45 of the received Association Request Message in the Waiting 
Queue, adds this SNIU's certificate to the message, calls the 
Fortezza API 56 to sign the message, generates a new ICMP 
Echo Request message, and passes both messages to the 
Host/Network Interface module 46 to transmit the messages 

50 to the destination host. If the messages are received by any 
other SNIU's before reaching the destination host, this 
process is repeated by each SNIU. 

If the destination host computer does not contain the 
Companion SNIU software, the host's communications pro- 

55 tocol stack software automatically converts the ICMP Echo 
Request message to an ICMP Echo Reply and returns it to 
the SNIU which sent it. However, the destination host does 
not contain any software which can process the Association 
Request Message; so it is ignored (i.e., deleted). 

60 If the destination host computer does contain Companion 
SNIU software, the host's data link layer software converts 
the stream of bits from the physical layer into packets which 
are passed to the Companion's Host/Network Interface 
module 46. The hardware address headers are stripped off of 

65 the packets and saved; and the packets are re-assembled into 
IP datagrams which are passed to the Message Parser 50 B. 
The ICMP Echo Request message is ignored; and the 
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Association Request Message is passed to the Fortezza API If an intermediate SNIU receives the PUD, the data is 

56 to have the signature verified. If valid, the message is passed through the data link layer software 70 to the network 

passed to the Association Manager module 54 which saves layer where the re-assembled datagram is passed to the 

the originating host and SNIU data and generates an Asso- Session Manager 48. The source IP address is to identify the 

ciation Grant Message. This message contains the SNIU's IP s re i ease key which ^ shared wjlh the prev j ous SNIU. The 

address (which is the same as the destination host's) the Forlezza 56 uses the release key to verify the message 

SNIU s certificate, the host s security level, and sealer keys authorization code. If not valid, the Session Manager 48 

",7» llln 8 SN l U _5 ld lh f Previous intermediate deletes lhe dat and caUs the Audit M 52 

SNIU (if there was one) The sealer keys (a.k.a. Message an ^ Eyen , Me f * 

Encryption Keys) are explained elsewhere. ^ rt to , , t , . 4 & , iL , 

Tne Fortezza API 56 is then called to sign the message 10 [ Cm ° T V D CS ^ e C ° de fr ? m * c dalagi ; am ' and US * S th f 

which is passed to the Host/Network Interface module 46. Uon ! c P KT addr !f l ° ^entity the release key shared with the 

The Association Grant Message is converted from an IP next SNIU - The Fortezza ^ 56 generates a new message 

datagram to network packets and passed back to the host's authorization code. The Session Manager 48 appends the 

hardware packet drivers (n the data link layer) for transmis- new code and P asses the datagram to the opposite port's 

sion back to the originating host. 15 Host Network Interface module. 

Any intermediate SNIU's which receive the Association Wnerl the P eer SNIU (i e., the destination IP address) 

Grant Message process the message up through the com- received the PUD and it has been reassembled into a 

munications stack protocol layers to the network layer which datagram, the Message Parser SOB passes the datagram to 

calls the Message Parser 50B to process the message. The the Session Manager 48. The source IP address is used to 

signature on the message is verified by the Fortezza API 56 20 identify the corresponding association key. The Fortezza 

and audited via the Audit Manager 52 if not valid. API 56 decrypts the original user datagram. The Session 

Otherwise, the validated message is processed by the Asso- Manager checks the message authorization code and the 

ciation Manager 54 module which removes and saves one of security levels of the source and destination hosts. If the 

the sealer keys (a.k.a. a release key) which will be used by code is valid (i.e. 3 the message was not modified during 

this SNIU and the previous SNIU (which generated the key) is transmission over the network) and the security levels 

to authenticate PUD messages exchanged via this associa- match, the decrypted datagram is passed to the Host/ 

lion in the future. The Fortezza API 56 is called to generate Network Interface 46 to be released to the destination host, 

and wrap another sealer key to be shared with the next SNIU If either is not correct, the Audit Manager 52 is called, 

in the association path. The new key and this SNIU's Mixed Enclave Operation 

certificate are appended to the message. The Fortezza API 56 30 Many network security devices provide privacy for all 

aligns the message. The Host/Network Interface 46 trans- traffic leaving a network through some type of security 

mits the message on its way back to the originating SNIU. measure such as encryption. Such deices are commonly 

The originating SNIU re-assembles the Association Grant referred to as Inline Network Encryptors (INE), which 

Message via the physical, data link 70 , and network layers prevent unauthorized users from viewing the communica- 

68 as previously described. The signature is validated and 35 tions traffic. The limitation to users of such INEs lies where 

audited if necessary. If valid, the Association Manager 56 the network user often needs to communicate with both 

uses the Fortezza API to unwrap the sealer key(s). If two users with INEs and users without INEs. An Internet, that 

keys are in the received message, the bottom key is a release contains both users who are equipped and not equipped with 

key to be shared with the first intermediate SNIU; and the an INE, is referred to as a "Mixed Enclave". Once an INE 

top key is an association key to be shared with the peer SNIU 40 is installed, a user can only communicate with other users 

(which granted the association). If there is only one key, it with similar INE's with the same keys, 

is the association key which is shared with the peer SNIU; Referring now to FIG. 7, there is shown a flow chart for 

and the association path does not contain any intermediate Mixed Enclave operation in accordance with the present 

SNIUs. Once the keys are stored and the Association Table invention. The SNIU can provide communications in a 

76 is updated, the association is established and the Session 45 mixed enclave environment between both SNIU equipped 

Manager 48 is called to transmit the original user datagram users and native network users without an SNIU 701. The 

which was stored in the waiting Queue prior to issuing the SNIU implements dynamic discovery of other SNIU 

Association Request Message. equipped users or hosts when communications are initiated. 

The Session Manager 48 enforces the security policy, If a particular communications path contains two or more 
determines whether IP datagrams received from host com- 50 SNIU units, communications is provided using encrypted IP 
puters can be transmitted via the network to their destination datagrams. If there is only one SNIU associated with a 
host, encapsulated these user datagrams in PUDs using the communications path, data packets are passed without 
sealer keys for the appropriate association. The security encryption or modification of any kind. Obviously, no data 
policy is enforced by comparing the security levels of the packets are passed or transferred that would result in data at 
host and destination. If the security levels are the same, the 55 a higher security classification being passed to a user or host 
Session Manager checks the Association Table and identi- at a lower security classification. Thus, the SNIU user can 
fled the appropriate peer SNIU and sealer key(s). The user simultaneously communicate with SNIU equipped and non- 
datagram is encrypted by the Fortezza API 56 using the SNIU equipped users. 

association key. If the association contains any intermediate The SNIU can be configured in several ways to exploit the 

SNIUs, the Fortezza API 56 calculates a message authori- 60 flexibility of mixed enclave operations. The SNIU can be 

zation code using the release key. The Session Manager 48 configured to only allow communications with other SNIU 

creates a PUD addressed from this SNIU to the peer SNIU, equipped users to provide absolute protection by preventing 

encloses the encrypted user datagram, appends the message any communications with non-SNIU equipped users 702. 

authorization code (if any), and passes the new datagram to Trie SNIU can be configured to provide mixed enclave 

the Host/Network Interface module 46 on the network-side 65 operation where the user can communicate securely with 

of the SNIU. The datagram is broken into packets and other SNIU users and insecurely with non-SNIU equipped 

transmitted as previously described. users 703. An SNIU can be configured to allow the user to 
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select either mixed enclave or SN1U only communications. Response which contains its hardware address, and a server 

The mixed enclave communications provides a mid range on the network returns a RARP Response containing an IP 

protection strategy where the user can determine when he address assigned to the requester's hardware address. All 

needs to communicate with untrusted sources, such as world ARP and RARP messages have the same format and are 

wide web sites. 5 contained within the frame data area of a single Ethernet 

The use of IP addressing 704, as disclosed above, is frame (they are not IP datagrams). The format of the ARP 
utilized to ascertain whether communications are occurring and RARP messages is shown in the Table of FIG. 3. 
between SNIU and SNIU users, or SNIU and native host Referring to FIG. 3, the HARDWARE TYPE is set to 
(non-SNIU) users 705. The previously discussed Address 0001 hex to indicate Ethernet. The PROTOCOL TYPE is set 
Resolution Protocol (ARP) allows a SNIU to find the 10 to 0800 hex to indicate IP addresses. The HLEN (hardware 
hardware address of another SNIU or host on the same address length) is set to 06 hex bytes, while the PLEN 
network, given its IP address. As noted previously, the (protocol address length) is set to 04 hex bytes. The OPERA- 
Reverse Address Resolution Protocol (RARP) allows a TION is set 0001 hex for an ARP request message, 0002 hex 
SNIU which only knows its hardware address to obtain an for ARP response message, 0003 hex for an RARP request 
IP address from the network. Through the association estab- 15 message or 0004 hex for RARP response message. The 
lishment messages 706, the SNIUs establish associations in SENDER'S HA contains the sender's 48 bit Ethernet hard- 
order to authenticate each other, exchange security ware address, while the SENDER'S IP contains the sender's 
parameters, and establish trusted sessions for eommunica- 32 bit IP address. The TARGET'S HA contains the target's 
tion. When a SNIU receives an IP datagram which is not 48 bit Ethernet hardware address, while the TARGET'S IP 
addressed to it and not a predetermined type, as discussed 20 contains the sender's 32 bit IP address, 
above, the SNIU assumes the IP datagram is from a native When a SNIU broadcasts a request message, it fills in all 
host 707. of the data and the target's hardware address field is set to 

In communications between an SNIU user and a non- 000000 hex for an ARP message. If the message is a RARP, 

SNIU user, the above discussed Waiting Queue is employed then the sender's and target's IP address fields are set to 

in part to control passage of information. For example, when 25 0000 hex. When the target machine responds, it fills in the 

a SNIU receives a user datagram from a native host (non- missing address and changes the operation field to indicate 

SNIU user) which is destined for another host or user for a response message. During an ARP, the target machine 

which there is no existing association, the SNIU stores the swaps the sender's and target's addresses so that the sender's 

user datagram in the Wailing Queue and transmits an asso- address fields contains its addresses and the target's address 

ciation request message. When the association grant mes- 30 fields contains the original requesting host's addresses, 

sage is received, the user datagram is removed from the During a RARP, the server stores its addresses in the 

Waiting Queue, the corresponding Schedule table is deleted, sender's address fields and returns the response to the 

the user datagram is encrypted and sent to the peer SNIU of original sender's hardware address. 

the association. If an Association grant message is never When a SNIU receives a message, it performs the fol- 

received, the Schedule Table entry expires, which calls a 35 lowing processes: 

subroutine to delete the user datagram. When a SNIU ARP Request — If an ARP Request message is received on 

receives a user datagram from a native host, the SNIU a SNIU 's port A, the untrusted software in port A's memory 

creates an entry, if one does not already exist, in the segment determines if the sender's IP address is in port A's 

receiving port's Association table for the source host's IP, ARP cache. If not, it creates a new entry in the ARP cache 

marks the association type as 'native host', sets the security 40 and inserts the sender's hardware and IP addresses, 

level to the receiving ports security level, and checks the Otherwise, the sender's hardware address is copied into the 

opposite port's Association table for the destination's IP entry (overwriting any previous address) and packets (if 

address. As discussed above, if an Association Table entry any) waiting to be sent to the sender's IP address are 

exists for the destination and the association type is a bona transmitted. If the target's IP address is in port A's address 

fide 'native host', the SNIU compares source and destination 45 list (i.e., a List of IP addresses which are accessed from port 

security levels to determine if an intended datagram can be B), the untrusted software returns an ARP Response mes- 

allowed to proceed 708. If a write up situation, the SNIU sage swapping the SENDER'S and TARGET'S addresses 

along with an anticipated message releases the intended and inserting port A's Ethernet hardware address into the 

datagram. If a write down situation, the SNIU determines if SENDER'S HA field. In either case, the untrusted software 

the datagram was predicted and sends or audits the antici- 50 passes the ARP Request Trusted Computing Base (TCB). 

pated message as described above. If a write equal, the The TCB checks port B's address list for the SENDER'S 

datagram is released to the destination. IP. If the SENDER'S IP is not in port B's address list, the 

Address Resolution Messages TCB determines whether the SENDER'S IP is releasable to 

The following is a discussion of the protocols and address port B. If releasable, the TCB inserts SENDER'S IP into port 

messaging applicable to both the hardware and software 55 B's address list. Secondly, the TCB determines whether a 

embodiments of the SNIU: proxy ARP Request should be broadcast from port B. If an 

Address Resolution Protocol (ARP) allows a SNIU to find ARP Response message was not returned by port A and the 

the hardware address of another SNIU or host on the same target's IP address is not in port A's ARP cache, then the 

network, given its IP address. The SNIU broadcasts an ARP sender's IP is releasable to port B. Thus, causing the TCB to 

Request message which contains its hardware and IP 60 create a proxy ARP Request message. The TCB inserts port 

addresses and the IP address of the target host. The target B's hardware and IP addresses in the SENDER'S address 

host (or other SNIU) returns to the requesting host an ARP fields, copies the target's IP address from the original ARP 

Response message which contains the hardware address of Request into the TARGET'S IP field and then signals port 

the target host (or other SNIU). B's untrusted software to broadcast the message. 

Reverse Address Resolution Protocol (RARP) allows a 65 Each time the TCB releases a proxy ARP Request, it 

SNIU which only knows its hardware address to obtain an creates an Anticipated Message in the form of a proxy ARP 

IP address from the network. The host broadcasts a RARP Response message. This proxy ARP Response message 
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contains the original sendees addresses in the TARGETS IP is releasable to port B. If re leasable, the TCB creates a 

fields, the target's IP address in the SENDER'S IP field and new entry in port B's ARP cache and inserts the TARGETS 

port A's hardware address is the SENDER'S HA field. This HA and IP. The TCB uses the TARGETS HA to find the 

message is saved in the Anticipated Message list for port A appropriate proxy RARP Response message in port B's 

and will be released to port A's untrusted software for 5 Anticipated Message List and copies the TARGETS IP and 

transmission, if the anticipated ARP Response message is SENDER'S IP into the Anticipated message. Then the TCB 

received on port B. Note that whether this message is signals port B's untrusted software to create a proxy RARP 

released may involve the TCB modulating ARP Requests Response message identical to the Anticipated Message, and 

from a high network to a low network in order not to exceed removes the message from the Anticipated Message list for 

the 100 bits per second covert channel bandwidth require- 10 port B. 

ment. Association Establishment Messages 

ARP Response — If an ARP Response message is received SNIUs establish associations in order to authenticate each 

on a SNIU's port A, the untrusted software in port A's other, exchange security parameters, and establish trusted 

memory segment determines if the sender's IP address is in sessions for communication. The SNIUs utilize a standard 

port A's ARP cache. If not, it creates a new entry in the ARP 15 ICMP Echo Request message to request an association and 

cache and inserts the sender's hardware and IP addresses. an ICMP Echo Reply message to grant an association. 

Otherwise, the sender's hardware address is copied into the When a host behind a SNIU attempts to communicate 

entry (overwriting any previous address) and packets (if with someone else over the network, the SNIU stores the 

any) waiting to be sent to the sender's IP address are datagram from the host in a waiting queue and transmits an 

transmitted. Finally, the untrusted software passes the ARP 20 ICMP Echo Request to the intended destination. This mes- 

Response to the TCB. sage is used to identify other SNIU units in the communi- 

The TCB checks port B's address list for the SENDER'S cations path and to carry the originating SNIU's security 

IP. If the SENDER'S IP is not in port B's address list, the parameters. The SNIU inserts the originating host's security 

TCB determines whether the SENDER'S IP is releasable to level, appends its certificate and then signs the message, 

port B. If releasable, the TCB inserts it into port B's address 25 Each SNIU unit which receives this message authenticates 

list. Secondly, the TCB checks the Anticipated Message list the message, saves a copy of the previous SNIU's certificate, 

for port B and determines whether the ARP Response was appends its certificate, and signs the message before sending 

due to a proxy ARP Request made for a request originally it to the destination. 

received on port B. If the SENDER'S IP matches an entry The destination host returns an ICMP Echo Reply to the 

in the Anticipated Message List and the message is re leas- 30 originating SNIU. The first SNIU to receive this message is 

able to port B, the TCB signals port B's untrusted software the terminating SNIU (i.e., closest to the destination) in the 

to create a proxy ARP Response message identical to the potential association's communications path. This SNIU 

Anticipated Message and then removes the message from determines if the association should be permitted (i.e., 

the Anticipated Message list for port B. would not violate the security policy). If permitted, the 

RARP Request — If a RARP Request message is received 35 SNIU grants the association, generates an encryption key for 

on a SNIU's port A, the untrusted software in port A's the association, and encrypts the key using the originating 

memory segment checks a flag to determine if the SNIU was SNIU's public key (from its certificate). If the Echo Request 

initialized to act as a RARP server for the network attached message contained an intermediate SNIU's certificate, the 

to port A. If not, the received message is ignored. Otherwise, SNIU also generates a release key and encrypts it using the 

the untrusted software passes the RARP Request to the TCB. 40 intermediate SNIU's public key. In either case, the SNIU 

The TCB determines whether the RARP Request can be removes its and the originating SNIU's security parameters 

released to port B. If releasable, it creates a proxy RARP and signatures from the ICMP Echo Reply, stores the 

Request message copying the TARGET'S HA from the encrypted key(s), inserts the destination host's security 

received message and inserting port B's addresses in the level, appends its certificate, signs the message and sends it 

SENDER'S HA and IP fields. Then the TCB passe the proxy 45 onto the originating SNIU. 

RARP Request message to port B's untrusted software for Each intermediate SNIU (if any exist) which receives the 

broadcast and creates an Anticipated message in the form of Echo Reply message authenticates the previous SNIU's 

a proxy RARP Response message. The TCB copies the signature, extracts the release key, generates a new release 

original TARGETS HA, inserts port A's hardware address in key for the next SNIU, encrypts the key using the public key 

the SENDER'S HA and saves it in the Anticipated Message 50 (from the certificate saved from the Echo Request message) 

list for port A. of the next SNIU, removes the previous intermediate 

RARP Response — If a RARP Response message is SNIU's certificate and signature, appends its own certificate 

received on a SNIU's port A, the untrusted software in port and signature, and sends the message on the return path. 

A's memory segment determines if the sender's IP address When the originating SNIU receives the ICMP Echo Reply, 

is in port A's ARP cache. If not, it creates a new entry in the 55 it authenticates the message and extracts the key(s). 

ARP cache and inserts the sender's hardware and IP Once the association is granted, the originating SNIU 

addresses. Otherwise, the sender's hardware address is cop- fetches the originating host's datagram from the waiting 

ied into the entry (overwriting any previous address) and queue and prepares to send it to the terminating SNIU in the 

packets (if any) waiting to be sent to the sender's IP address newly established association. The SNIU uses the associa- 

are transmitted. Finally, the untrusted software inserts the 60 tion key to encrypt the datagram for privacy. The SNIU 

TARGET'S IP into port A's address list and passes the further stores the encrypted datagram and the encryption 

RARP Response to the TCB. residue into a new datagram from the originating SNIU to 

The TCB checks port B's address List for the SENDER'S the terminating SNIU. If the association contains interme- 

IP. If the SENDER'S IP is not in port B's address list, the diate SNIUs, the originating SNIU uses the release key to 

TCB determines whether the SENDER'S IP is releasable to 65 calculate a second encryption residue and appends it to the 

port B. If releasable, the TCB inserts it into port B's address datagram. Finally, the SNIU transmits the protected user 

list. Secondly, the TCB determines whether the TARGETS datagram to the peer SNIU in the association. 



05/12/2004, EAST Version: 1.4.1 



5,828,832 

15 16 

When the protected user datagram is received by an using the same association may still exist. The data structure 

intermediate SNIU (if any in the path), the intermediate for a token of the Association Table is shown in the Table of 

SNIU fetches the release key corresponding to the previous FIG. 5. 

SNIU and uses the release key to validate the datagram. If Referring to FIG. 5, NEXT is a pointer to the next token 
valid, the SNIU removes the release key residue from the 5 in the table or list. PREVIOUS is a pointer to the previous 
datagram and checks to determine whether there are more token in the table or list. IP ADDRESS is the IP address of 
intermediate SNIUs in the path before reaching the termi- the source/destination, while PEER SNIU IP ADDRESS is 
nating SNIU. If another intermediate SNIU exists, the the address of the other terminating SNIU for the associa- 
release key corresponding to the next intermediate SNIU is tion. ASSOCIATION KEY POINTER points to the associa- 
ted to calculate a new release residue which is appended to 10 tion MEK in the Sym„Key table. RELEASE KEY 
the datagram. In either case, the datagram is sent on its way POINTER points to the release MEK in the Sym__Key table, 
out the opposite port from which it was received. The ASSOC-TYPE is set to 0001 hex for 'pending', 0002 

When the terminating SNIU receives the protected user hex for 'host' (i.e., the entry is for a host destination), 0003 

datagram, it uses the association key corresponding to the hex for 'sniu' (i.e., the entry is for a SNIU destination), 0004 

originating SNIU to decrypt and validate the datagram. If the 15 hex for 'native host' (i.e., no peer SNIU) or 0005 hex for 

source and destination hosts are at the same security level 'audit catcher'. The RELKEY-TYPE is set to 0001 hex for 

(i.e., a write-equal situation), the decrypted datagram is sent 'in' (i.e., use to validate release key residue), 0002 hex for 

out the opposite port to the destination host. If the source 'out' (i.e., use to add release key residue) or 0003 hex for 

host has a lower security level than the destination (i.e., a 'both'. SECURITY- LEVEL indicates the security level of 

write-up situation), the SNIU predicts the response from the 20 the source/destination, while SPARE is an unused byte to 

destination and saves it before sending the decrypted data- keep addressing on a 32-bit boundary, 

gram to the destination host. Referring to FIG. 6, there is shown the data structure of 

If the source host has a higher security level than the a token for the Sym__Key Table according to the present 

destination (i.e., a write-down situation), the received data- invention. NEXT is a pointer to the next token in the table 

gram (i.e., a response to a previous datagram from the lower 25 or list, while PREVIOUS is a pointer to the previous token 

level host) was predicted by the SNIU which sent the in the table or list. DISTINGUISHED NAME is the 128 byte 

protected datagram. Therefore, this SNIU is assured that the name in certificate from the other SNIU using this key. MEK 

classification of the received datagram is dominated by the is the 12 byte wrapped key (association or release) shared 

lower Level destination host, so that the datagram is released with the another SNIU. IV is the 24 byte initialization vector 

to the destination. If a SNIU receives a user datagram from 30 associated with the MEK. CERTIFICATE POINTER points 

a native host which would be a write-down to the destination to the other SNIU's certificate in the Certificate table, 

host and no predicted datagram is found, the received INDEX is a Fortezz a card key register index which indicates 

datagram is erased and the attempted write-down is audited. if and where the key is loaded (1-9 are valid key register 

Message Processing Tables indexes, while 0 indicate that the key is not loaded on the 

There are three tables which are used to process 35 Fortezza). SPARE is an unused byte to keep addressing on 

in-coming and out-going messages including the Associa- a 32-bit boundary, 

tion Table, the Symmetric Key Table(Sym_Key) and the Message Flag 

Certificate Table. Each SNIU has to Association Tables, one Any message (IP datagram) which is generated or modi- 

for each port. Each entry contains data corresponding to a fled by a SNIU unit contains a Message Flag in the last four 

particular source or destination IP address. The Sym_Key 40 bytes of the datagram. The first byte is the message type 

table contains data corresponding to a particular message field, the second byte is the message format field and the 

encryption key (MEK) which could be used as a release key third and fourth bytes are the Flag. Note that all SNIU 

or an association key. The Certificate table contains recently message types are signed except for a Protected User 

received certificates from other SNIU's. Datagram (PUD) which uses message encryption key 

Each table consists of a linked list of tokens in which the 45 (MEK) residues for integrity and authentication. The fol- 

data for an entry in the table is stored in a token. The tokens lowing is a list of message types: Audit Event, Audit Catcher 

for each table have a unique data structure and are linked List, Audit Mask, Association Close, Association Request, 

together in 'free' lists during initialization. When a new Association Grant. Association Unknown, Protected User 

entry is made in one of the tables, a token is removed from Datagram, Receipt, and Certificate Revocation List. The 

the free list for that table's tokens, the data for the new entry 50 following are message formats: Signed Type 1 (source 

is inserted in the appropriate fields of the token and the token SNIU's certificate and signature), Signed Type 2 (source and 

is linked at the top of the table. When an entry is removed intermediate SNIU's certificates and signature), PUD Type 

from a table, the 'previous' and 'next' tokens are linked, the 1 (Association MEK residue), and PUD Type 2 (Association 

data fields in the token are cleared and the token is linked at MEK and Release MEK residues), 

the bottom of the appropriate free list. Whenever the data in 55 Waiting Que and Schedule Table 

an entry is used, the token is removed from the table and The Waiting Que is used to store IP datagrams for 

relinked at the top of the table. In this way the oldest (i.e., potential future processing based on an anticipated event, 

least used) entry is at the bottom of the table. For every entry made in the Waiting Que, a corresponding 

If a new entry is needed and the free list is empty, the entry is made in the Schedule Table. The Schedule Table is 

bottom token is removed from the table, the data fields are 60 used to automatically process entries in the Waiting Queue 

cleared, the new entry's data is inserted and the token is if they have not been processed within some predetermined 

linked at the top of the table. In addition, when a SNIU amount of time (i.e., the anticipated event does not occur), 

removes the bottom (oldest unused) token in the Sym_Key The Schedule Table entry contains a time-out field (which is 

Table, it also removes every token in the Association Table set to the current time plus some reasonable delta represent - 

which pointed to the removed key. A SNIU does not send a 65 ing the maximum waiting period) and a function pointer 

Close Association Message when a certificate, key or Asso- (which indicates which subroutine should be called if time 

ciation Table entry is removed because many valid entries expires before the Waiting Queue entry is processed). The 
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Schedule Table is checked in the main executive loop of the The decrypt operation uses the release key and release Key 

TCB, expired entries are removed and the corresponding IV. The release key I V is never changed since the encrypted 

datagrams in the Waiting Queue are processed by the data is always guaranteed to be unique even if the original 

designated subroutine. datagram is not. The release key residue is appended to the 

For example, when a SNIU receives a user datagram from 5 protected user datagram. The completed protected user 

a native host which is destined for another host for which datagram is then transmitted, 

there is no existing association, the SNIU stores the user Received Message Processing 

datagram in the Waiting Queue and transmits an Association When a SNIU receives an IP datagram, it checks the 

Request message. When the Association Grant message is destination address in the header and determines if it is the 

received, the user datagram is removed from the Waiting io intended recipient. Then, the SNIU checks the last four bytes 

Queue, the corresponding Schedule Table entry is deleted, of the IP datagram for the Message flag and determines the 

the user datagram is encrypted and sent to the peer SNIU of type and format of the received message, 

the association. If an Association Grant message is never Destination SNIU Message Processing 

received, the Schedule Table entry expires which calls a When a SNIU receives an IP datagram which is addressed 

subroutine to delete the user datagram from the Waiting 15 to it, the message should be one of the following messages: 

Queue. an Audit Event, Audit Catcher list, Audit Mask, Association 

Another example is when the SNIU sends an Audit Event Close, Association Request, Association Grant, Association 
message to an Audit Catcher. The transmitted datagram is Denial, Association Unknown, Protected User Datagram, 
stored in the Waiting Queue. When the Receipt message is Receipt and Certificate Revocation List. If it is not, the SNIU 
received from the Audit Catcher, the original Audit Event 20 audits the event. The only exceptions are ICMP datagrams 
datagram is removed from the Waiting Queue and the which are processed by the receiving port's un trusted soft- 
corresponding Schedule Table entry is deleted. If the Sched- ware and not passed to the trusted computing base, 
ule Table entry expires, the designated subroutine is called Audit Event — If the SNIU is not configured to be an Audit 
which re-transmits the Audit Event message stored in the Catcher, it will audit the event sending the source IP address 
Waiting Queue and a new entry is made in the Schedule 25 of the received message to its primary Audit catcher. 
Table. If the SNIU is configured to be an Audit Catcher, it 
Generating and Exchanging MEKs verifies the signature on the message, increments its 

Message Encryption Keys (MEKs) are generated during received audit event sequence number, generates a time 

the association establishment process (previously described) stamp, and prints the sequence number, time stamp, source 

and are exchanged via the Association Grant Message. 30 IP address, and ASCII character string from the message. 

When a SNIU generates an MEK, it simultaneously gener- Once the event has been recorded, the Audit catcher SNIU 

ates an initialization vector (IV). generates a Receipt Message (copies the audit event counter 

When a SNIU exchanges an MEK with another SNIU, it from the received message and inserts it in the message 

generates a random number, RA, which is required to number field), sends it, and checks the receiving port's 

encrypt (i.e., wrap) the MEK. The key exchange algorithm 35 Association Table for an entry for the source of the received 

is designed so that only the sending and receiving SNIUs can message. If an entry does not exist (i.e., this was the first 

decrypt the MEK and use it. The sender wraps the MEK for communication from the source SNIU), the Audit Catcher 

transmission using the destination's public Key RA, RB makes an entry, marks the association type as 'sniu', and 

(which is always set-1) and the sender's private key. IVS sends the SNIU the current audit mask, 

which were generated with release keys are transmitted in 40 Audit Catcher List — The SNIU verifies the signature on 

the clear with the wrapped MEK in the Association Grant the message, stores the new list of Audit catchers in the 

Message, while IVS which were generated with association Configuration table, generates a receipt message, and audits 

keys are ignored. The recipient unwraps the key using its the event. 

private key RA, RB, and the sending SNIU's public key. Audit Mask — the SNIU verifies the signature on the 

Once unwrapped, the safe exchange is complete. 45 message, stores the new audit mask in the Configuration 

Each SNIU re-wraps the MEK using its storage key (Ks), Table, generates a Receipt Message, and audits the event (in 
stores the MEK and the IV (if the MEK is a release key) in case someone else other than the Audit Catcher is distrib- 
ute Sym__Key Table, stores the pointer to the MEK in the uting new audit masks). In addition, if the receiving SNIU 
Association Table and stores the DN (of the other SNIU is an Audit Catcher, it distributes the new audit mask to 
sharing this MEK) in the Sym„Key Table entry. 50 every destination in the Association Table with an associa- 
Using MEKs and IVS tion type of 'sniu'. 

Message Encryption Keys (MEKs) are used as association Association Close — When a SNIU receives a valid pro- 

and release keys to provide confidentiality, integrity and tected User Datagram, but cannot find the destination's 

authentication of user datagrams during an association Association Table entry, it sends an Association close mes- 

between two SNIUs. IVS are used to initialize the feedback 55 sage back to the originating SNIU and audits the event. The 

loop in the Skipjack encryption algorithm for most modes of originating SNIU verifies the signature on the received 

operation. Encrypting identical data using the same MEK, Association Close Message, extracts the original destination 

but different IVS, will produce different cipher text. In fact, host's IP, removes the host's entry from its Association 

the Fortezza card utilized requires the user to generate a new Table and audits the event. It does not remove the peer 

IV for each encryption event in order to assure that each 60 SNIU's entry nor entries from the Sym_Key table as they 

message looks different when encrypted. might be supporting other associations. 

When a SNIU encrypts a user datagram it first generates Association Request — This message can only be received 

a new IV for the association key, encrypts the datagram, by a SNIU which originally transmitted it as an ICMP echo 

appends the encryption residue for integrity and authentica- request to some unknown destination which converted it to 

tion purposes, and appends the new IV. If the association 65 an Echo reply and returned it to the originator without 

involves intermediate SNIUs, the SNIU performs a decrypt encountering another SNIU. Therefore, the SNIU uses the 

operation on the newly encrypted datagram, residue and IV source IP address to find the destination's entry in the 
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Association Table, changes the association type from 'pend- 
ing' to 'native host', sets the security level to that port's 
security level, finds the original host's user datagram in the 
Waiting Queue, removes the corresponding entry from the 
Schedule table, and compares the source and destination 5 
security levels to determine if the user program can be sent 
to the destination. If the comparison indicates a write-up 
situation, the SNIU generates and saves an anticipated 
message and releases the original datagram to the destina- 
tion port. If a write down situation, the SNIU determines if 10 
the data gram was predicted and sends the anticipated 
message or audits as previously described. If a write equal, 
the datagram is released to the destination port. This proce- 
dure is repeated for each entry in the Waiting Queue which 
is intended for the same destination. 15 

Association Grant — The SNIU verifies the signature in 
the datagram and updates the receiving port's Association 
Table entries for the host destination and peer SNIU. The 
SNIU finds the entry for the destination host, changes the 
association type from 'pending' to 'host', copies the peer 20 
SNIU's IP, extracts and unwraps the association MEK (and 
release MEK if needed), stores the re -wrapped key(s) in the 
Sym__Key table, marks the release key type as 'out' (if a 
release key exists), copies the destination host's security 
level, and determines if an entry exists for the peer SNIU. If 25 
not, the SNIU creates a new entry for the peer SNIU, copies 
the association and release key pointers and release key type 
from the destination host's entry, and marks the association 
type as 'sniu\ 

Once receiving the port's Association Table has been 30 
updated, the SNIU finds the original hosts user datagram in 
the waiting Queue, removes the corresponding entry from 
the Schedule table, and compares the source and destination 
security levels to determine if the user datagram can be sent 
to the destination. If the source's security level is dominated 35 
by (i.e., less than or equal to) the destination's security level, 
the SNIU creates a Protected user Datagram (PUD). The 
SNIU sets the destination to the peer SNIU's IP, sets the 
protocol type to indicate a SNIU Message, uses the asso- 
ciation key to encrypt the entire received datagram, inserts 40 
the ciphertext and IV, appends the association residue, 
generates and inserts a release residue (if the destination 
host's Association Table entry contains a pointer to a release 
key), appends the appropriate SNIU Message Flag, and 
sends the datagram. If the source host is not dominated by 45 
the destination (i.e., potential write down, the attempted 
write down is audited. This procedure is repeated for each 
entry in the Waiting Queue which is intended for the same 
destination. 

Association Unknown — A SNIU sends an Association 50 
Unknown message (and generates audit notices) when a 
protected user datagram is received and a corresponding 
Association Table entry does not exist. The message is sent 
back to the source SNIU and contains the destination 
SNIU's IP address. When a SNIU receives an Association 55 
Unknown Message, it deletes every entry in the Association 
Table in which the peer SNIU address matches the returned 
destination SNIU IP. Subsequent user datagrams from the 
same host sent to the same destination will initiate an 
Association Request to re-establish the association. Any 60 
SNIU involved in establishing an association for which it 
already has keys (association and/or release keys) will 
suggest the same key as originally used. 

Protected User Datagram — the SNIU uses the source IP to 
find the appropriate entry in the receiving port's Association 65 
Table and retrieve the association key to decrypt and validate 
the received datagram. If the decryption residue does not 
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match, the even is audited. Otherwise, the SNIU uses the 
destination host's IP to find the appropriate entry in the 
opposite port's Association Table, retrieves the destination 
host's security level, and compares it to the security level in 
the received datagram. If a write-up situation, the SNIU 
generates an anticipated message. However, regardless of 
the relative security levels, the decrypted and validated user 
datagram is sent to the destination host. 

If a terminating SNIU receives a PUD and validates the 
residue but cannot deliver the user datagram because it 
cannot find the destination host in the Association Table, 
then the SNIU returns an Association close message to the 
originating SNIU (containing the destination host's IP) and 
audits the event. 

Receipt — A Receipt message is sent by an Audit catcher 
to a SNIU for Audit Catcher Request and Audit Event 
messages. The SNIU uses the message number in the 
received datagram to locate the saved copy of the original 
message in the Waiting Queue and remove it and the 
corresponding Schedule Table entry. If the original message 
was an Audit Catcher Request Message, the SNIU locates 
the Association Table entry for the Audit catcher and 
changes the association type from 'pending' to 'audit 
catcher'. If time expires in the Schedule Table entry before 
the Receipt Message is received, the SNIU will retransmit 
the original message. If no receipt is received after TBD 
attempts, the SNIU will switch to the next Audit Catcher in 
the list. If all Audit Catchers are attempted without success, 
the SNIU will check a configuration parameter to determine 
whether to continue without audit or halt. 

SNIUs issue Receipt messages to Audit catchers for Audit 
Catcher List, Audit Mask, and Certificate Revocation List 
messages. When an Audit Catcher receives a receipt, it uses 
the returned message number to remove the copy of the 
message from the Waiting Queue and the corresponding 
Schedule table entry. 

Certificate Revocation List — if a Certificate revocation 
List (CRL) is received, the SNIU returns a receipt to the 
source and checks the Sym__Key Table for any keys which 
were received from (or sent to) another SNIU with a revoked 
certificate, the SNIU deletes the certificate from the Certifi- 
cate Table (if it is still there), deletes the Sym„Key Table 
entry, and deletes every entry in the Association Table which 
pointed to the key. Note that deleting a table entry means to 
unlink the token from the table, clear the token's memory, 
and re-link the token in the token's free list. 
Non-Destination SNIU Message Processing 

When a SNIU receives an IP datagram which is not 
addressed to it, the message should be one of the following 
types of Dragonfly formatted messages. If it is not, the SNIU 
will assume the IP datagram is from a native host. 

Audit Event — The SNIU verifies the signature on the 
message and releases the message out the opposite pen 

Audit Catcher List — The SNIU verifies the signature on 
the message and releases the message out the opposite port. 

Audit Mask — The SNIU verifies the signature on the 
message and releases the message out the opposite port. 

Association Close — The SNIU verifies the signature on 
the message and releases the message out the opposite port. 

Association Request — When a SNIU receives an Asso- 
ciation Request it first checks the IP header to determine if 
the datagram is an ICMP Echo Request or an ICMP Echo 
Reply. 

If it is an ICMP Echo Request, the SNIU validates the 
signature at the bottom of the message and checks the 
receiving port's Association Table for an entry with the 
originating SNIU's IP address. If the receiving SNIU cannot 
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find an entry, it creates one, marks the association type as 
'pending', stores the previous SNIU's certificate in the 
Certificate Table (if it wasn't already there), updates the 
Sym_Key Table entry for the Distinguished Name (DN), 
and stores the pointer to the Sym__Key Table entry in the 5 
release key pointer field in the Association Table entry. If the 
previous SNIU was an intermediate SNIU (i.e., the Message 
Format field of the SNIU Message Flag is 'Signed Type 2'), 
this SNIU marks the release key type field as 'out' and 
removes the previous SNIU's certificate and signature. In 10 
either case, this SNIU appends its certificate and signature 
and sends the message out the other port. It does not make 
any entry in the out-going port's Association Table. 

If it is an ICMP Echo Reply, this SNIU is the terminating 
SNIU which must generate the Association Grant Message, is 
Before the SNIU can validate the received message, it must 
reconstruct the message to match the form it was in when the 
SNIU signed it before the destination host converted the 
ICMP Echo Request into an ICMP Echo Reply. Therefore, 
the SNIU exchanges the source and destination IP addresses 
in the datagram header and changes the type field in the 
ICMP header from a request (8) to a reply (0). Then the 
SNIU validates the signature at the bottom of the newly 
reconstructed message using its own public key. If the 
signature cannot be validated, the event is audited. 

If the ICMP Echo Reply is valid, the SNIU creates or 
updates three Association Table entries. First, it creates an 
entry (if it doesn't already exist) in the receiving port's 
Association Table for the original destination host (using the 
destination IP from the modified datagram header), marks 
the association type as 'native host' and stores the receiving 
port's security level in the security level field. Second, it 
updates the entry in the opposite port's Association Table for 
the peer SNIU (using the source IP from the modified 
datagram header). If the release key type is marked 'out' or 
'both', then the association path contains at least one inter- 
mediate SNIU; therefore, the SNIU extracts the peer SNIU's 
certificate from the datagram, stores it in the Certificate 
Table, stores the pointer to the certificate and the DN in a 
Sym_Key Table entry, and stores the pointer to the Sym_ 
Key Table entry in the association key pointer field of the 
Association Table entry. If there aren't any intermediate 
SNIUs, the pointer in the release key pointer field is copied 
to the association key pointer field; and the release key 
pointer field is cleared. In either case the association type is 
marked as 'sniu'. The third Association Table entry is for the 
originating host. It's IP and security level are in the data 
portion of the received datagram. The security level is 
copied into the entry, the association type is marked as 
'host', and the rest of the data is copied from the peer SNIU 
entry. Finally, the SNIU generates the association key (and 
if necessary, the release key) and stores the key(s) in the 
Sym__Key Table entry (s). 

Once the Association Table entries are updated, an Asso- 
ciation Grant Message is generated. The SNIU uses the peer 
(i.e., originating) SNIU's IP for the destination, uses the 
original destination host's IP for the source, and marks the 
protocol and type fields to indicate an ICMP Echo Reply. 
The SNIU inserts its IP address, its certificate, its host's 
security level, the association key data (wrapped key and 60 
RA), and if necessary, the release key data (the wrapped key, 
RA and IV). The SNIU Message Flag is inserted at the 
bottom marking the type as Association Grant and the 
format as Signed Type 1 to indicate only one certificate. The 
message is signed and sent. 65 

Association Grant — The SNIU validates the signature at 
the bottom of the received datagram and if not correct, audits 
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the event. Otherwise, since it is not the destination, the SNIU 
is an intermediate SNIU somewhere in the path between the 
two peer SNIUs. The SNIU creates an entry (if one doesn't 
already exist) in the receiving port's Association Table for 
the IP of the terminating SNIU which granted the association 
(note that the terminating SNIU's IP is not in the header of 
the received datagram, rather it is in the data area), marks the 
association type as 'sniu', marks the release key type as 'in' 
(if the format is 'Signed Type V) or 'both' (if the format is 
'Signed Type 2'), extracts the release key data (i.e., the 
wrapped MEK, RA and IV), unwraps and stores the release 
key in the Sym__Key Table, stores the release key IV in the 
same Sym_Key Table entry, stores the pointer to the release 
key in the Association Table, stores the certificate in the 
Certificate Table, and stores the pointer to the certificate and 
the DN in the Sym__Key Table entry. 

Next, the SNIU uses the destination IP address in the 
header of the received Association Grant Message to find the 
destination's entry in the opposite port's Association Table. 
If the association type is 'pending', the SNIU uses the 
release key pointer to fetch the saved certificate of the next 
SNIU, generates release key data (an MEK, RA, and IV), 
stores the wrapped MEK and IV in the Sym_Key Table 
entry, and changes the association type to 'sniu'. If the 
association type is 'NULL', the SNIU changes it to 'in'; 
otherwise, it is marked as 'both'. 

Finally, the SNIU rebuilds the Association Grant Message 
to send on to the destination. The SNIU copies the received 
datagram up to and including the association key data and 
the certificate of the SNIU which originated the Association 
Grant Message, inserts its certificate and the release key 
data, and signs and sends the datagram. 

Association Unknown — The SNIU verifies the signature 
on the message and releases the message out the opposite 
port. 

Protected User Datagram — The SNIU uses the source IP 
address to find the appropriate entry in the receiving port's 
Association Table, fetches the release key, and verifies the 
release key residue. If the release residue is not correct the 
datagram is deleted and the event audited. Otherwise, the 
SNIU uses the destination IP address to find the appropriate 
entry in the opposite port's Association Table, fetches the 
release key, generates the new release residue, overwrites 
the old release residue, and sends the datagram on to the 
destination. 

Receipt — The SNIU verifies the signature of the message 
and releases the message out the opposite port. 

Certificate Revocation List — The SNIU verifies the sig- 
nature on the message and releases the message out the 
opposite port. 

Native Host Message — When a SNIU receives a user 
datagram from a native host, the SNIU creates an entry (if 
one doesn't already exist) in the receiving port's Association 
Table for the source host's IP, marks the association type as 
'native host', sets the security level to the receiving port's 
security level, and checks the opposite port's Association 
Table for the destination's IP address. 

If an entry does not already exist for the destination, the 
SNIU creates a new entry, marks the association type as 
'pending', stores the received datagram in the Waiting 
Queue, makes a corresponding entry in the Schedule Table, 
creates an Association Request Message and sends it. 

If an Association Table entry exists for the destination and 
the association type is 'pending', the SNIU stores the 
received datagram in the Waiting Queue, linking it to other 
datagrams for the same destination. 

If an Association Table entry exists for the destination and 
the association type is 'host', the SNIU compares the source 
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host's security level to the destination host's security level. 
If the source's security level is dominated by (i.e., less than 
or equal to) the destination, the SNIU creates a Protected 
User Datagram (PUD). The SNIU sets the destination to the 
peer SNIU's IP, sets the protocol type to indicate a SNIU s 
Message, uses the association key to encrypt the entire 
received datagram, inserts the ciphatext and IV, appends the 
association residue, generates and inserts a release residue 
(if the Association Table entry contains a pointer to a release 
Key), appends the appropriate Dragonfly Message Flag, and 10 
sends the datagram. If the source host is not dominated by 
the destination (i.e., a potential write down), the SNIU 
determines if this datagram was anticipated. If a matching 
datagram was predicted the anticipated datagram is trans- 
formed into a PUD (as described above) and sent. If an 15 
anticipated message is not found, the attempted write-down 
is audited. 

If an Association Table entry exists for the destination and 
the association type is any other bona fide type, i.e., 'native 
host', 'sniu', or 'audit catcher', the SNIU compares the 20 
source and destination port's security levels to determine if 
the datagram can be allowed to proceed. If the comparison 
indicates a write-up situation, the SNIU generates and saves 
an anticipated message and releases the original datagram to 
the destination port. If a write-down situation, the SNIU 25 
determines if the datagram was predicted and sends the 
anticipated message or audits as previously described. If a 
write-equal, the datagram is released to the destination port. 

The SNIU may be implemented in the form of a software 
program executed on a general purpose computer coupled as 30 
a server between a host machine and the network. 
Alternatively, it may be programmed as a network commu- 
nications program resident in and executed from the host 
machine. However, for security purposes, the preferred form 
of the SNIU is a closed module having the security program 35 
functions resident in ROM and executed by a dedicated 
microprocessor. The closed module can incorporate the 
communications link or modem to the network. 

It is to be will be understood that the embodiments 
described herein are merely exemplary of the principles of 40 
the invention, and that a person skilled in the art may make 
many variations and modifications without departing from 
the spirit and scope of the invention. All such variations and 
modifications are intended to be included within the scope of 
the invention as defined in the appended claims. 45 

What is claimed is: 

1. A method for communicating on a network having a 
secured plurality of users utilizing multi-level network secu- 
rity devices, each multi-level network security device being 
operable in a first and second mode, respectively, and an 50 
unsecured plurality of users employing no network security 
devices, said method comprising the steps of: 
sending a communication from any first user; 
intercepting said communication by a first multi-level 

network security device; 55 
discarding said communication if said communication 
violates security parameters associated with said first 
multi-level network security device; and, 
in said first mode, sending said communication from said 60 
first multi-level network security device to any second 
user; and, 

in said second mode, encrypting said communication 
using said first multi-level network security device, 
sending said encrypted communication to a second 65 
multi-level network security device, decrypting said 
communication using said second multi-level network 
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security device, and sending said decrypted communi- 
cation from said second multi-level network security 
device to a third user selected from said secured 
plurality of users. 

2. The method of claim 1, wherein said multi-level 
network security interfaces are transparent to said users and 
the network. 

3. The method of claim 1, wherein said step of sending 
said encrypted communication to a second multi-level net- 
work security interface further comprises the steps of: 

intercepting said encrypted communication sent by said 

first multi-level network security interface by a third 

multi-level network security interface; 
validating a signature of said first multi-level network 

security interface using said third multi-level network 

security interface; and, 
sending said first multi-level network security interface 

encrypted communication from said third multi-level 

network security interface to said second multi-level 

network security interface. 

4. The method in accordance with claim 1, further com- 
prising using Internet protocol (IP) addresses for identifying 
each of said secured plurality of users employing multi-level 
network security interfaces, respectively, and said remaining 
users employing no network security interface. 

5. The method in accordance with claim 1, further com- 
prising each multi -level network security interface using 
association establishment messages for authenticating other 
multi-level network security interfaces. 

6. The method in accordance with claim 1, further com- 
prising using association establishment messages for 
exchanging security parameters between said multi-level 
network security interfaces. 

7. The method in accordance with claim 1, further com- 
prising said first multi-level network security interface 
assuming that datagrams received which are not addressed 
to said first multi -level network security interface are from 
one of said remaining users employing no network security 
interface. 

8. The method in accordance with claim 1, wherein for 
communications between a secured user selected from said 
secured plurality and an unsecured user selected from said 
remaining users employing no network security interface, at 
least one multi-level network security interface employs a 
waiting queue to influence passage of information. 

9. The method in accordance with claim 1, wherein said 
second user is selected from said secured plurality, and 
receives initial information from said first user who is 
selected from said remaining users employing no network 
security interface and which has not already established 
communications with said second user, and said first multi- 
level network security interface creates an entry in an 
association table indicative of at least said first users' IP 
address and association type. 

10. The method in accordance with claim 9, wherein said 
first multi-level network security interface compares the 
security level of said second user to that of the first user for 
determining if information to the first user can be allowed to 
proceed. 

11. The method in accordance with claim 10, wherein 
when the second user is at a higher security level than the 
first user and the first user is writing up to the second user, 
information intended for the second user is released. 

12. The method in accordance with claim 10, wherein 
when the second user is at security level equal to the first 
user, the first multi-level network security interface permits 
information transfers between said first and second users. 
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13. The method in accordance with claim 12, wherein 
when the second user is at a higher security level than the 
first user and the second user is writing down to the first user, 
the first multi-level network security interface determines if 
the information intended for the first user is predicted. S 

14. A method for mixed enclave communications over a 
network including both secured and unsecured users, said 
method comprising the steps of: 

permitting communications over the network between 
one of said secured users and one of said unsecured 10 
users; 

discovering dynamically by said secured user whether a 
user initiating communications is one of said secured 
users or one of said unsecured users; and, 

controlling passage of information between said one of 
said secured users and said one of said unsecured users 
for securing given information residing with said one of 
said secured users against transference to said one of 
said unsecured users when not permissible. 2Q 

15. The method in accordance with claim 14, wherein the 
step of discovering includes using Internet Protocol (IP) 
addresses for identifying the secured and unsecured users. 
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16. The method in accordance with claim 14, wherein the 
step of discovering includes using association establishment 
messages for said secured users authenticating each other. 

17. The method in accordance with claim 14, wherein the 
step of discovering includes using association establishment 
messages for the secured users exchanging security param- 
eters. 

18. The method in accordance with claim 14, wherein for 
communications between one of the secured users and one 
of the unsecured users, the secured user employs a waiting 
queue to influence passage of information. 

19. The method in accordance with claim 14, wherein 
when one of the secured users receives initial information 
from one of the unsecured users that is not already 
established, the secured user creates an entry in an associa- 
tion table indicative of at least the unsecured user's IP 
address and association type. 

20. The method in accordance with claim 19, wherein the 
secured user further compares its security level to that of the 
unsecured user for determining if information to the unse- 
cured user can be allowed to proceed. 

***** 
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